Author:
RAMU MEDA
Date:
Port
overview
|
Standard port |
Protocol/Service |
Comment |
|
21 |
FTP |
File transfer
protocol |
|
23 |
telnet |
Remote login |
|
25 |
SMTP |
Simple mail
transfer protocol |
|
80 |
HTTP |
WWW transmission
protocol |
|
88 |
Kerberos/UDP |
|
|
110 |
POP3 |
Post office
protocol |
|
119 |
NNTP/TCP |
|
|
135 |
RPC/TCP |
|
|
161 |
SNMP |
Simple network
management protocol |
|
389 |
LDAP |
Lightweight
directory access protocol |
|
443 |
HTTPS |
HTTP/SSL |
|
636 |
LDAPS |
LDAP over SSL |
|
993 |
SSL |
Secure Socket
Layer |
|
1099 ( Naming) |
JRMP |
Java remote
method protocol |
|
8001/538 (
Naming ) |
IIOP |
Internet
Inter-Orb Protocol |
Scenarios:
·
HTTP/HTTPS
– internet sites
·
RMI-IIOP
– intranet environment; interoperability requirements (EJB-EJB, EJB-CORBA, etc.)
·
RMI-JRMP
– intranet with an all Java environment
Firewalls:
Firewalls provide
protection by:
·
packet
filtering
o
IP
blocking – source or destination IP
o
Port
blocking – e.g. only allow well-known ports such as 80, 443, 25, etc.
·
protocol
filtering – e.g. no FTP
·
HTTP/HTTPS aren’t generally affected by firewalls as
ports 80 and 443 are normally allowed through. However, HTTP
clients cannot generally accept asynchronous updates (push model) as
more than likely the client will be prevented from running a socket server.
·
Most
of the time, IIOP and JRMP are affected by firewalls as they use dynamic
port allocation for object servers and use less well-known ports.
·
Although
IIOP and JRMP can be tunneled through HTTP this isn’t ideal – the
main benefit of being connection-based protocols is then lost.
HTTP
·
The
HTTP protocol is based on a request/response paradigm.
·
The
communication generally takes place over a TCP/IP connection on the
Internet.
·
The
default port is 80, but other ports can be used. This does not preclude
the HTTP/1.0 protocol from being implemented on top of any other protocol on
the Internet, so long as reliability can be guaranteed.
·
The
HTTP protocol is connectionless and stateless After the server
has responded to the client's request, the connection between client and server
is dropped and forgotten. There is no "memory" between client
connections. The pure HTTP server implementation treats every request as if
it was brand-new, i.e. without context.
·
An
extensible and open representation for data types HTTP uses Internet Media
Types (formerly referred to as MIME Content-Types) to provide open and
extensible data typing and type negotiation.
HTTPS(Secure Hypertext Transfer Protocol)
·
HTTP1.0
uses tear-down
o
Client
opens/closes socket connection to the web server every time
·
HTTP1.1
uses keep-alive (a persistent connection).
o
Client
holds socket connection open over multiple requests.
o
Still
regarded as connection-less as it’s acceptable for the client or server to drop
the connection at any time (e.g. Apache uses a 15 sec timeout on keep-alive
sockets), client will re-establish the connection.
o
Client/server
can use pipelining – i.e. sends multiple requests/responses down
the socket at once.
·
Pros:
o
simple
request/response mechanism
o
allowed
through firewalls (most of the time)
o
widely
supported / deployed
o
extensible
- supports tunneling of arbitrary data;
o
custom
request types/response content
·
Cons:
o
stateless
- hence non-transactional
o
insecure
- hence HTTPS
o
inefficient
- e.g. MIME encoding can make files bigger
o
doesn’t
support “push” model
HTTPS
·
Stateful
/ connection-based.
·
Web
protocol developed by Netscape and built into its browser that encrypts and
decrypts user page requests as well as the pages that are returned by the Web
server.
·
HTTPS
is really just the use of Netscape's Secure Socket Layer (SSL) as
a sublayer under its regular HTTP application layer.
·
HTTPS
uses default port 443
instead of HTTP port 80 in its interactions with the lower layer, TCP/IP.
·
SSL
uses a 40 or 128-bit key size for the RC4 stream
encryption algorithm, which is considered an adequate degree of encryption for
commercial exchange.
·
URL
that starts with https://. When you click "Send," to send the page
back to the catalog retailer, your browser's HTTPS layer will encrypt it. The acknowledgement
you receive from the server will also travel in encrypted form, arrive with an
https:// URL, and be decrypted for you by your browser's HTTPS sublayer
·
HTTPS
and SSL support the use of X.509 digital certificates from the
server so that, if necessary, a user can authenticate the sender.
·
SSL is
an open, nonproprietary protocol that Netscape has proposed as a
standard to the World Wide Consortium (W3C).
·
HTTPS is not to be confused with SHTTP, a
security-enhanced version of HTTP developed and proposed as a standard by EIT.
·
Pros:
o
secure
– only “in-the-clear” at client / server
o
allowed
through firewalls (most of the time)
o
widely
supported / deployed
·
Cons:
o
computationally
expensive – excluding dedicated hardware, HTTPS can only process 10% of the traffic
HTTP can
o
low
performance compared to HTTP
o
Admin
overhead – renewing certs, etc.
·
Each
party (client/server) may hold multiple SSL sessions.
·
Each
session may include multiple secure connections.
·
SSL
handshake Process :
o
The
client and server exchange capabilities (e.g. SSL version,
ciphers available, etc.). The server includes it’s certificate in the response
o
client
verifies the CA’s digital signature in the server certificate
using the CA’s public key
o
if OK,
the client generates a pre-master secret, encrypts it using the
server’s public key and sends it to the server [if using client certificates,
the client response includes the pre-master secret and the client certificate.
The server verifies the CA’s digital signature in the client certificate using
the CA’s public key]
o
the
server decrypts the pre-master secret using it’s private key
o
using
the pre-master secret, the client and server use an agreed algorithm to
independently generate the master secret
o
the
master secret is then used to generate a set of session keys
(symmetric keys for speed)
o
the
client and server exchange messages confirming that the encrypted session has started.
Subsequent SSL records are compressed and encrypted / signed using the session
keys
Note on Dashed line in the above figure: An RMI-IIOP client
cannot necessarily access all existing CORBA objects. The semantics of
CORBA objects defined in IDL are a superset of those of RMI-IIOP objects,
which is why an existing CORBA object's IDL cannot always be mapped into an
RMI-IIOP Java interface. It is only when a specific CORBA object's semantics
happen to correspond with those of RMI-IIOP that an RMI-IIOP client can call a
CORBA object. The dotted arrow indicates a connection that is sometimes -- but
not always -- possible.
IIOP / RMI-IIOP
·
Stateful
/ connection-based.
·
no
default port – the
GIOP/IIOP implementation will dynamically assign ports when an object server
instance binds to a name
·
CORBA
and IIOP assume the client/server model of computing in which a client program
always makes requests and a server program waits to receive requests from
clients.
·
GIOP à CDR
formatting rules + Message formats + message-transport assumptions.
·
IIOP (InterObject Internet
protocol) à General
Inter-ORB Protocol (GIOP) + TCP.
·
Interoperable
Object Reference (IOR) à address for the program ( part of the
address is based on the server's port number and Internet Protocol (IP) address
). The IOR contains a set of profiles (details of host, port, object instance,
etc.) so that a client knows where to connect / send messages back and forth.
·
Common
Data Representation (CDR) provides a way to encode and decode
data so that it can be exchanged in a standard way.
·
CORBA is not the only architecture that uses
IIOP
·
CORBA
is an integration technology, not a programming technology. It is specifically
designed to be the glue that binds disparate programming technologies together
·
RMI-IIOP
à RMI+CORBA à combines RMI's easy programming features +
CORBA's interoperability
·
Pros:
o
supports
propagation of security/transactional context
o
an
open standard from the OMG
o
Mostly
used for intranets / extranets – i.e. clients behind corporate firewalls or VPN
connections Clients communicate with servers via an IOR (Interoperable
Object Reference).
o
Interoperability
– Java clients can call C++ servers; Cobol client can call Java server, etc.
o
Legacy
integration
o
Designed
for generic remote object invocation - type safe, extensible
o
Inbuilt
support for security and transactions
o
CORBA
and IIOP also guarantee that objects can describe their interfaces at
run-time. The ability to do this in object and component models is
often called "introspection." This capability allows
users much more powerful browsing capabilities. Rather than just
downloading documents, users can interactively discover and inquire about a
wider range of more sophisticated object services.
·
Cons:
o
Firewalls
– servers bound to arbitrary ports so firewall can’t be configured with an IIOP
port; can use HTTP Tunneling. Can be supported with an IIOP proxy but “push”
model is still problematic
o
Performance
– all method invocations are remote (possibly over the internet)
o
Pass-by-reference
– only supports remote references, can’t use pass-by-value (until CORBA 2.3)
·
The
two major changes CORBA accepted were the Objects
by Value and the
·
RMI-IIOP
client cannot necessarily access an existing CORBA object. If you do want to
use Java to access CORBA objects that have already been written, Java IDL is an
alternative to RMI-IIOP. Using Java IDL (a core part of the Java 2 Platform),
you can access any CORBA object from Java.
·
Sun's recommendation for usage of
RMI-IIOP and Java IDL.
·
If you want to use Java to access existing
CORBA resources, Java IDL is recommended.
·
If,
conversely, you want to export Java RMI resources to CORBA users, you
should use RMI-IIOP.
JRMP
·
Also
known as the RMI Wire Protocol, to send method invocations
and associated parameters and to return values and exceptions from one
Java virtual machine (JVM) to another.
·
JRMP
is the default protocol for RMI – stateful / connection-based.
·
JRMP
is a simple protocol consisting of five messages, plus an extra five for
multiplexing flow control.
·
The
default port for the RMI registry / JNDI name server is 1099,
object servers will be dynamically assigned ports by the RMI runtime.
·
Pros:
§
Richer
feature set than IIOP
§
pass
by reference or by value;
§
distributed
GC;
§
stub
download ,
§
Single
multiplexed connection
§
allows
to move code ( behaviour) in addition
to data (state)
§
Data
type can be any Java objects. Any Java objects can be passed as arguments.
Arguments has to implement the serializable interface
§
carries
Java's security model to ensure that the code downloaded is safe to run
§
allows
pass by value references
§
uses
Java as both an interface definition and an implementation language
§
uses
a URL-based naming scheme
·
Cons:
o
Firewalls
– servers bound to arbitrary ports; TTP tunneling limited
o
Performance
– all method invocations are remote (possibly over the internet)
o
RMI
lacks followings with respect to IIOP
§
Interoperability
- only works in a Java environment In other words, RMI objects can talk only to
other RMI objects. With RMI, you cannot invoke objects written in other
languages or vice versa.
§
Dynamic
invocations and interface
repositories.
§
Wire
protocol for security and transactions. RMI is both proprietary and
lightweight. It was not designed to interoperate with other ORBs or
languages. Unlike CORBA's IIOP, RMI is not a suitable backbone for the Internet
or intranets; it lacks services IIOP provides.
§
Unlike
CORBA, RMI offers no concept of services
§
RMI
also does not include any object activation policies, such as
those used by CORBA ORBs.
§
server
objects written in Java using RMI suffer from poor performance due to
limitations inherent in the Java virtual machine
§
While
RMI is a viable option for smaller-scale applications to be written
entirely in Java, CORBA provides the foundation for integration of
existing objects with new code and also the ability to scale for the future
§
Lacks
IIOP’s support for transaction/security context propagation ( RMI has only the
naing service. CORBA has support for Naming, Security, Transactions, Events and
Concurrency control )